-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature/new modifier implementation #356
base: develop
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a suggestion on refactoring caliper.Caliper
into two classes to make it easier to assemble modifier/spec components.
caliper_modifier_modes["mode"] = var | ||
modifier_list.append(caliper_modifier_modes) | ||
# Add time as the last mode | ||
modifier_list.append({"name": "caliper", "mode": "time"}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(question) When you mentioned having to order things yourself, is this what you mean?
In a separate conversation, you mention that this is so "In this case, the time mode is always added last to the modifier list which adds the CALI_CONFIG variable after each of the CALI_CONFIG_MODE variables have been defined. "
I'm not clear on how this achieves that. Is time
the only modifier mode that defines CALI_CONFIG
?
) | ||
elif self.spec.satisfies("caliper=cuda"): | ||
cuda_support = ( | ||
self.spec.satisfies("caliper=cuda") and True |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and True
looks vestigial
# set package spack specs | ||
package_specs = {} | ||
|
||
if not self.spec.satisfies("caliper=none"): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I get the impression that some combinations of caliper=...
are not allowed. I don't know if we support conflict
yet, but FWIW you can raise an exception here for forbidden combinations.
from benchpark.experiment import Experiment | ||
|
||
|
||
class Caliper(Experiment): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(suggestion, not a problem) IIRC you mentioned that caliper
would never be instantiated as an experiment itself. FWIW, this could move from var/exp_repo/experiments/caliper/
to lib/benchpark
, possibly into a new subdir like lib/benchpark/experiment_addons
} | ||
} | ||
|
||
def compute_modifiers_section(self): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a suggestion for refactoring this to make it easier to add analogs to caliper
:
Experiment.__init__
(in the base classExperiment
) callsExperiment.initialize
- Move all functionality in
caliper.Caliper
except for variant declaration intocaliper.Helper
Amg2023.initialize
setshelpers = [caliper.Helper()]
Experiment
(the base class) handles tacking on extra modifiers from all.helpers
- It can also take care of
caliper_package_specs
- It can also take care of
The benefit of this organization is that you can add more functionality (that defines other modifiers/specs) without having to modify functions in this class other than .initialize
.
New modifier implementation using experiment.py